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1.  INTRODUCTION 


In  1995,  the  U.S.  Army  Research  Laboratory’s  (ARL’s)  Advanced  Simulation 
and  High  Performance  Computing  Directorate  (ASHPCD)  and  Weapons 
Technology  Directorate  (WTD)  combined  several  research  projects  into  an 
interactive  demonstration.  This  real-time  demonstration  featured  a  combat  scenario 
wherein  a  live  soldier  interacted  with  constructive  entities  on  a  virtual  reality 
battlefield. 

A  unique  feature  of  this  demonstration  was  that  the  combat  scenario  was 
designed  in  real-time  by  a  Generic  Scenario  Generator  (GSG)  system.  In  this 
system  the  scenario  was  described  in  a  general  manner  which  we  call  the  Combat 
Model  Independent  Generic  Scenario  (CMIGS)  format.  This  CMIGS  description 
was  then  compiled  into  a  form  understood  by  a  specific  computer-generated  forces 
application.  Computer-controlled  forces  could  then  be  placed  and  given  orders 
within  the  simulated  environment.  These  computer-generated  forces  then  interacted 
with  a  live  soldier  who  independently  maneuvered  and  executed  his  own  command 
decisions  on  the  battlefield.  The  live  soldier  was  presented  with  a  three- 
dimensional  (3D)  virtual  battlefield  perspective  via  the  ARL  Stealth  viewing 
system.  The  Direct  Fire  Module  Map  (DFM  Map)  application  provided  a  real-time 
two-dimensional  (2D)  view  of  the  battlefield.  Distributed  Interactive  Simulation 
(DIS)  protocol  was  used  to  couple  each  of  these  components  together  into  a 
seamless,  real-time,  interactive  simulation. 

The  scenario  generator  and  DFM  Map  are  part  of  the  Simulation  for 
Technology  Assessment  System  (STAS).  The  interactive  soldier  system  and  ARL 
Stealth  viewer  are  part  of  the  Untethered  Land  Warrior  (UTLW)  research  project. 
The  computer-generated  forces  application  was  the  Direct  Fire  Module  (DFM) 
combat  simulation.  Subsequent  sections  of  this  report  describe  each  of  these  major 
components  in  more  detail  as  they  pertain  to  the  demonstration. 

Figure  1  illustrates  the  architecture  used  in  the  demonstration. 
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Figure  1.  Demonstration  Configuration 


2.  STAS 


STAS  is  a  prototype  system  designed  to  use  simulation  technology  to  assess 
the  impact  and  interactions  of  new  and  proposed  materiel,  tactics,  and  technology 
on  military  systems  and  concepts  (Smith,  to  be  published).  A  major  component  of 
STAS  is  the  Generic  Scenario  Generator  (GSG).  GSG  is  a  collection  of  software 
programs  that  allow  a  user  to  rapidly  define  a  generic  combat  scenario  for  use  as 
input  to  a  combat  simulation.  It  uses  an  open-ended  approach  in  that  its  output,  or 
product,  is  a  scenario  description  file  that  is  independent  of  any  specific  combat 
simulation.  The  file  is  a  complete  and  generic  description  of  the  combat  scenario 
including  specifications  for  the  location  and  use  of  models  that  describe  the 
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content,  makeup,  or  behavior  of  particular  elements  in  the  scenario  such  as  troops, 
vehicles,  weapons,  and  even  environmental  conditions. 

Another  major  component  of  STAS  is  the  Scenario  Translator.  Its  function 
is  to  translate  the  scenario  description  file  into  specific  inputs  targeted  for  a 
particular  combat  simulation.  For  demonstration  purposes,  the  Scenario  Translator 
was  developed  to  generate  scenario  inputs  for  the  DFM  combat  simulation.  These 
inputs  were  generated  by  translating  the  scenario  description  file  resulting  from  a 
user  created  scenario.  See  Figure  2. 

GSG  provides  the  capability  to  specify  the  scenario  environment  using 
predefined  or  user-definable  terrain.  Manmade,  environmental,  and  meteorological 
conditions  are  optional  aspects  that  can  be  added  to  the  physical  description  of  the 
environment.  A  unit  editor  is  available  for  creating,  selecting,  and  task  organizing 
friendly  and  enemy  forces  within  the  scenario.  Individual  unit,  equipment,  and 
vehicle  capabilities  are  definable  and  modifiable.  Initial  placement  of  units  is 
currently  done  on  a  2D  overhead  view  of  the  terrain.  Unit  movement  is  prescribed 
by  specifying  routes  comprised  of  way  points  for  each  unit. 


STAS 


Figure  2.  Simulation  for  Technology  Assessment  System 
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3.  DEMONSTRATION  DESCRIPTION 


This  section  describes  the  STAS  concept  demonstration.  Detailed 
descriptions  on  the  STAS  components  used  in  the  demo  follow  this  section. 

Physically,  all  the  applications  and  devices  were  connected  on  the  same  local 
area  ethemet  network  (Figure  1).  On  this  link,  applications  communicated  using 
DIS  Protocol  Data  Units  (PDUs).  The  Stair-Stepper  and  DFM  passed  each  other 
DIS  PDUs  containing  information  relating  to  what  their  simulated  entities  were 
doing  and  where  they  were  on  the  virtual  battlefield.  DFM  Map  and  ARL  Stealth 
monitored  and  digested  this  network  traffic.  These  two  applications  used  this 
information  to  visually  display  the  battle  as  it  developed  (i.e.,  showing  movements, 
weapons  fired,  detonations,  damaged  units,  etc.).  Before  any  of  this  could  occur, 
the  computer-generated  forces  had  to  be  told  what  to  do.  This  was  done  with  the 
generic  scenario  generator  (GSG)  portion  of  STAS. 

The  demonstration  started  with  GSG  being  used  to  choose  which  type  of 
units  would  participate  in  the  virtual  battle.  Combat  units  were  selected  in  GSG 
from  a  database  of  unit  descriptions.  Unit  selection  occurred  from  within  a  GSG 
program  called  the  "Unit  Editor."  Symbols  (icons)  for  the  selected  units  were 
visually  displayed  on  a  graphics  terminal.  These  icons  were  then  moved  (via  a 
mouse  pointer)  from  the  Unit  Editor  window  and  placed  on  the  GSG  map.  (The 
GSG  map  is  a  STAS  2D  map  application  displaying  the  virtual  battlefield 
environment.)  Once  placed  on  the  GSG  map,  units  could  then  be  given  planned 
maneuver  routes  by  selecting  a  series  of  objective  points  on  the  map.  In  this  way, 
all  units  were  placed  and  given  objectives  (if  any)  until  the  scenario  description 
was  completed.  GSG  placed  the  just-built  scenario  description  into  the  CMIGS 
language  format.  Once  the  STAS  user  was  satisfied  with  the  scenario  description, 
he/she  then  chose  the  combat  model  to  execute  it  (e.g.,  in  this  case,  DFM  was 
selected). 

Upon  selecting  DFM,  the  STAS  Scenario  Translator  translated  the  CMIGS 
description  into  a  format  that  DFM  could  understand.  DFM  then  used  this 
translated  battle  description  to  begin  its  real-time  execution  of  the  scenario.  Units 
were  placed  on  the  virtual  battlefield  and  the  simulation  commenced.  The  stair- 
stepper  soldier  had  already  been  on  the  battlefield  throughout  the  scenario  building 
process.  However,  it  was  not  until  the  STAS  user  executed  DFM  that  the  stair- 
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stepper  soldier  could  observe  computer-generated  forces  (if  they  were  within  sight) 
and  interact  with  them  in  a  limited  fashion. 

The  stair-stepper  soldier  was  able  to  interact  with  the  DFM-controlled 
computer-generated  forces  by  engaging  these  virtual  threat  forces  with  a  simulated 
hand-held  antitank  weapon.  As  the  soldier  fired  this  weapon,  a  DIS  Fire  PDU  was 
sent  out  on  the  network.  DFM  would  receive  a  Fire  PDU  and  "fly”  the  projectile 
(using  a  simple  internal  trajectory  model)  to  determine  what  it  hit.  If  a  DFM- 
controlled,  computer-generated  tank  was  hit,  then  DFM  used  another  internal  model 
to  determine  the  extent  of  any  damage,  and  reflected  the  damage  in  subsequently 
sent  Entity  State  PDUs.  The  demonstration  ended  after  a  predetermined  amount 
of  time. 


4.  DFM  MAP 


DFM  Map  is  an  X-Window-based  data-driven  display  program  used  to 
provide  a  top-down  2D  view  of  the  battlefield  during  a  DIS  exercise.  This  program 
provides  a  clear,  uncluttered,  perspective  of  the  entire  battlefield.  DFM  Map  uses 
DIS  PDUs  to  drive  its  display.  DIS  events,  gleaned  primarily  from  Entity  State, 
Fire,  and  Detonation  PDUs  are  depicted  through  icon  symbols  representing  units, 
weapons  fire,  and  detonations.  Markings  described  in  Entity  State  PDUs  are 
reflected  through  unit  icon  symbols.  The  map  also  provides  the  capability  to 
change  the  area  of  view  by  zooming  in  or  out  by  a  preset  factor  or  zooming  to  a 
window  (an  area  outlined  using  the  computer  mouse)  view.  Figure  3  depicts  DFM 
Map  as  it  monitors  a  DIS  exercise  (Red  2  is  shown  firing  and  impacting  a  munition 
against  Blue  7). 
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Figure  3.  DFM  Map  Example  Display 

5.  UNTETHERED  LAND  WARRIOR 

The  Untethered  Land  Warrior  project  is  a  research  effort  that  is  exploring 


system  and  body  sensors.  The  portable  computer  will  maintain  the  DIS  "state"  of 
the  individual  soldier  and  send  out  soldier-initiated  DIS  events  through  appropriate 
PDUs. 


The  UTLW  project  will  allow  an  individual  soldier  to  fully  interact  with  both 
the  real  and  virtual  environment  and  with  all  virtual  and  constructive  forces.  The 
soldier  will  be  able  to  "kill"  or  damage  the  constructive  and  virtual  forces,  and 
likewise  be  "killed"  or  damaged  by  them. 

For  this  demonstration,  the  UTLW  used  a  commercially  available 
stair-stepper  to  simulate  moving  through  a  virtual  environment. 

A  tracker  was  used  to  monitor  the  head  position  of  the  soldier  in  order  to 
update  the  UTLW’s  view  of  the  environment  as  rendered  by  the  ARL  Stealth 
viewer.  The  ARL  Stealth  is  an  SGI  Performer-based,  3D  graphics  rendering 
program  that  was  used  in  the  demo  to  depict  the  view  of  the  virtual  environment 
and  all  related  DIS  events.  For  the  demo,  the  view  depicted  was  "slaved"  to  the 
view  of  the  UTLW  soldier. 


Figure  4  displays  the  demonstration  UTLW  configuration  in  use.  The  soldier 
is  seen  viewing  the  ARL  Stealth  display  while  traversing  through  the  virtual 
environment  via  the  stair-stepper. 


Figure  4.  The  Demo  UTLW  Stair-Stepper  Device  in  Use 
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a  main  gun,  a  coaxial  machine  gun,  an  anti-tank  missile  system,  and  possibly  more 
weapon  systems.)  Heterogeneous  forces  refers  to  the  fact  that  numerous  types  of 


6.1  Terrain  in  DFM 


DFM  was  designed  to  incorporate  Variable  Resolution  Terrain  (VRT); 
alternatively,  it  can  network  to  a  "terrain  server,"  or  simply  read  a  static  terrain 
database.  VRT  is  a  continuous  mathematical  function  that  can  be  used  to  model 
terrain.  Its  advantage  is  that,  since  it  is  a  continuous  mathematical  function,  it  has 
infinite  resolution  and  is  differentiable  (almost)  everywhere  (Wald  1992).  This  is 
an  extremely  useful  feature  when  one  requires  "micro  terrain"  sections  of  the 
battlefield.  Memory  can  be  efficiently  allocated  for  small  "micro  terrain"  sections 
and  freed  once  this  high  detail  is  no  longer  necessary.  (Though  this  benefit  comes 
at  the  penalty  of  computation  time.)  For  purposes  of  the  demonstration,  VRT  was 
not  required,  and  in  order  to  be  compatible  with  the  other  applications  in  the 
simulation,  DFM  used  the  same  static  digitized  terrain  database  as  the  other 
participants. 


6.2  Modifiable  Entity  Capabilities  in  DFM. 


DFM  can  be  used  as  an  evaluation  tool  for  weapon  system  concepts.  Basic 
weapon  system  entities  are  built  in  a  way  to  make  it  relatively  easy  to  swap 
different  ammunition,  weapons,  engines,  and  other  components.  This  can  be 
accomplished  without  code  modification. 

More  unpredictable  modifications  to  entity  capability  can  be  achieved  at  a 
software  engineering  level  by  replacing  subroutine  calls.  In  this  respect,  DFM  is 
designed  in  a  structured,  object  based,  and  modular  fashion  to  reduce  the  confusion 
created  by  making  such  changes.  An  example  of  one  such  late  entry  entity 
adaptation  has  been  active  protection.  Active  protection  is  a  defensive  weapon 
concept.  An  active  protection  component  is  co-located  with  the  entity  and  attempts 
to  intercept  an  attacking  munition  in  order  to  damage,  deflect,  or  destroy  that 
munition  -  before  it  reaches  the  entity.  One  model  that  simulates  an  active 
protection  system  is  ACTPRO  (Wald  1994).  DFM  incorporates  active  protection 
by  compiling  the  ACTPRO  model  in  the  form  of  a  software  function  (subroutine) 
call. 
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Future  plans  for  DFM  are  to  incorporate  "plug-and-play"  capabilities  into  its 
design.  This  will  conceptually  allow  DFM  to  call  separate  stand-alone  programs 
(such  as  ACTPRO)  that  are  external  from  DFM.  A  major  advantage  is  that  the 
separate  model  will  not  have  to  be  interfaced  at  a  functional  (or  subroutine)  level. 
(This  eliminates  the  need  for  software  changes.)  How  to  best  implement 
"plug-and-play"  is  an  ongoing  investigation  at  ARL. 


6.3  Special  Modification  for  the  Demonstration. 


Special  consideration  was  made  for  the  individual  soldier  simulator  (the 
stair-stepper  device).  Unfortunately,  at  this  point  in  the  UTLW  project,  there  were 
no  physical  controls  to  elevate  or  depress  the  soldier’s  weapon.  (A  LAW  II 
shoulder-launched  rocket  was  the  weapon  used  for  the  demo.)  For  this  reason,  the 
man-in-the-loop  would  almost  certainly  never  hit  a  target  (except  perhaps  by 
accident),  since  he  had  no  control  to  superelevate  his  weapon  to  the  correct  target 
range.  Furthermore,  software  controlling  the  stair-stepper  did  not  keep  track  of 
where  its  fired  munitions  flew,  and  consequently  could  not  issue  a  Detonation  PDU 
when  it  impacted  something. 

A  special  module  was  added  to  DFM  to  overcome  these  temporary 
deficiencies  in  the  following  manner.  When  DFM  detected  a  fire  event  from  the 
stair-stepper,  it  first  looked  to  see  if  the  soldier  was  facing  towards  any  potential 
targets.  If  not,  then  DFM  reissued  the  Fire  event  with  the  launch  vector  field  set 
to  the  maximum  weapon  range.  If,  on  the  other  hand,  the  soldier  was  facing  any 
potential  targets,  DFM  then  decided  which  target  was  in  range  and  at  the  same  time 
closest  to  the  soldier’s  orientation  (direction  he  was  facing).  If  a  target  was  so 
qualified,  DFM  used  that  target’s  range  to  calculate  a  fire  control  superelevation. 
Then  DFM  reissued  the  Fire  event  using  this  superelevation  solution.  The  launch 
orientation  was  still  set  for  the  direction  the  soldier  was  facing.  In  this  way,  the 
soldier  could  hit  any  target  in  range  (provided  he  was  correctly  aiming  at  it). 
Following  the  fire  event,  DFM  kept  track  of  where  the  round  flew.  Upon  the 
munition  striking  another  entity,  or  the  terrain,  DFM  issued  a  Detonation  PDU  on 
behalf  of  the  stair-stepper.  (It  should  be  noted  that  DIS  protocol  states  that 
applications  are  responsible  for  sending  messages  (PDUs)  to  other  simulations  to 
inform  them  of  any  observable  actions.  Hence,  DFM’s  counterfeiting  the  stair- 
steppers ’s  identity  in  this  way  could  be  viewed  as  a  mild  departure  from  DIS  protocol.) 
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The  detonating  munition  triggered  various  things  to  happen  in  other 
demonstration  applications.  For  instance,  DFM  Map  would  place  a  flashing 
"detonation"  icon  at  the  point  of  impact  and  draw  a  line  from  there  back  to  the 
stair-stepper  icon  (in  order  to  indicate  that  the  stair-stepper  was  responsible  for  this 
detonation).  The  ARL  Stealth  application  presented  a  visual  detonation  effect. 
DFM  actuated  a  sound  server  to  simulate  the  explosion.  (Even  though  DFM  sent 
out  the  Detonation  PDU,  the  PDU  was  sent  on  behalf  of  the  stair-stepper. 
Therefore  DFM  behaved  as  if  it  had  no  prior  knowledge  until  it  was  notified  of  the 
detonation  event.)  DFM  also  evaluated  where  the  detonation  occurred,  and,  if  one 
of  its  entities  was  struck,  it  conducted  appropriate  vulnerability  assessment  against 
that  entity.  (Which,  in  turn,  might  trigger  the  ARL  Stealth  to  present  further  visual 
effects  -  depending  on  the  resulting  entity  damage.) 


7.  CONCLUSION 


The  Simulation  for  Technology  Assessment  System  has  demonstrated  its 
potential  for  use  within  a  multiplatform  distributed  simulation  environment 
containing  both  virtual  (UTLW)  and  constructive  (DFM)  simulations.  One  of  its 
greatest  assets  is  its  capability  to  create  scenarios  in  a  generic  environment  and 
have  simulations  execute  and  evaluate  these  scenarios.  The  Combat  Model 
Independent  Generic  Scenario  (CMIGS)  language  provides  the  means  by  which  a 
number  of  simulations  may  utilize  these  scenarios.  Currently,  DFM  is  the  only 
simulation  with  a  CMIGS  translator.  It  is  hoped  that  in  the  future  other  simulations 
will  have  CMIGS  translators. 

Additional  work  is  required  to  further  explore  and  develop  the  concepts  that 
were  demonstrated.  In  STAS,  the  GSG  needs  expanded  capabilities  for  creating 
and  modifying  scenarios  and  their  respective  elements  (units,  equipment,  objectives, 
capabilities,  physical  environment,  etc.).  The  CMIGS  language  needs  further 
development  in  order  to  provide  a  descriptively  richer  environment.  DFM  should 
be  used  to  continue  investigating  techniques  to  develop  reconfigurable  combat 
simulations  that  support  variable  resolution  fidelity  combat  and  physical  models 
that  can  be  dynamically  interchanged  with  like  models.  STAS  is  a  vehicle  by 
which  these  technological  challenges  can  be  researched. 
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WTD  Weapons  Technology  Directorate 
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